home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98b.txt / 000112_icon-group-sender _Mon Jun 29 08:41:59 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id IAA06764
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Mon, 29 Jun 1998 08:41:59 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA00698; Mon, 29 Jun 1998 08:41:47 -0700
  7. Sender: rwg@fns.com
  8. Message-Id: <35970F72.40125E54@fns.com>
  9. Date: Sun, 28 Jun 1998 23:52:18 -0400
  10. From: Robbie Gilbert <rwg@fns.com>
  11. Organization: Fujitsu Network Communications
  12. X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
  13. Mime-Version: 1.0
  14. To: jeffery@segfault.cs.utsa.edu
  15. Cc: Icon Mailing List <icon-group@optima.CS.Arizona.EDU>
  16. Subject: Re: Forcing Generator to Return a List of Values
  17. References: <199806290337.WAA12295@segfault.cs.utsa.edu>
  18. Content-Type: text/plain; charset=us-ascii
  19. Content-Transfer-Encoding: 7bit
  20. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  21. Status: RO
  22. Content-Length: 2116
  23.  
  24. Clint,
  25.  
  26. Thanks for the input!  Yes, I've already discovered some coding problems and am
  27. working on fixing them.  This is only for a small (as you say, around 10) number
  28. of iterations, so it shouldn't be too expensive in that sense, but being a newbie
  29. I didn't realize co-expressions were memory-intensive.
  30.  
  31. I realized I was only saving one line of code but I hate to use a line of code for
  32. something as trivial as initialization. Collecting all the values and assigning
  33. them seems such a natural operation, especially if this is an operation that can
  34. be reused.  As you say, though, the performance hit may not justify the
  35. succintness of the expression.  I will do some timings and see.
  36.  
  37. Thanks again,
  38.  
  39. Robbie
  40. rwg@fns.com
  41.  
  42. Clinton Jeffery wrote:
  43.  
  44. > [Robbie Gilbert provides a helper procedure and uses co-expression invocation
  45. > p{} to solve his problem of turning a generator's result sequence into a list.]
  46. >
  47. > Hi Robbie,
  48. >
  49. > You've got some coding problems to fix, but when you fix them the general
  50. > approach you describe will work and is attractively concise.  However, it is
  51. > not cheap.  If you need to do this 10 times in your program, you have a
  52. > great solution.  If you need to do it many thousands of times, you had best
  53. > not create a new co-expression every time you capture a generator's results.
  54. > The reason is that each co-expression requires substantial memory for its
  55. > own stack, and the memory for co-expressions is not allocated and reclaimed
  56. > in the same, efficient way that most Icon values are.
  57. >
  58. > This is just my impression.  I am a big co-expression advocate and would
  59. > welcome corrections and anecdotes from persons who have happily used
  60. > thousands of co-expressions in a single program!
  61. >
  62. > Remember, you are only going to save one line of code over:
  63. >         L := []
  64. >         every put(L, generator_expression)
  65. >
  66. > Perhaps if you do an experiment and collect some timings, that will influence
  67. > you!
  68. >
  69. > Cheers,
  70. >
  71. > Clint Jeffery, jeffery@cs.utsa.edu
  72. > Division of Computer Science, The University of Texas at San Antonio
  73. > Research http://www.cs.utsa.edu/research/plss.html
  74.  
  75.  
  76.  
  77.